Authentication vs Authorization: Access-Control Guide for Student Projects
A practical guide to RBAC, object ownership, IDOR/BOLA prevention, policy middleware, and negative security testing.
A login screen can work perfectly while the application behind it remains unsafe.
Consider a college ERP. A student enters the correct password and reaches the dashboard. The system has authenticated the student. But what happens when that student changes /results/1042 to /results/1043 in the browser or sends the modified request through Postman? If the server returns another student’s marks, authentication succeeded while authorization failed.
That distinction matters in any multi-user project. This guide shows how to design, implement, document, and test access control in a final-year application.
Quick Answer
Authentication verifies identity: “Who are you?” Authorization evaluates access: “What are you allowed to do with this resource?”
A secure request usually follows this sequence:
- The application verifies the user’s credentials.
- It creates a protected session or validates an access token.
- Authentication middleware attaches the verified identity to the request.
- Authorization logic checks the requested action, resource, ownership, role, tenant and relevant context.
- The server allows or denies the operation.
Authorization is not a one-time check performed during login. It must be enforced by the backend whenever a protected resource or function is requested. The OWASP Authorization Cheat Sheet recommends least privilege, deny-by-default rules and permission checks on every request.
Authentication vs Authorization
|
Area |
Authentication |
Authorization |
|
Core question |
Who are you? |
What may you do? |
|
Common inputs |
Password, OTP, passkey, identity token |
Role, permission, ownership, attributes, policy |
|
Output |
Verified identity, session or token |
Allow or deny decision |
|
Typical methods |
Sessions, MFA, OIDC, passkeys |
RBAC, ABAC, ReBAC, ACLs |
|
Common failure |
Account takeover or session hijacking |
IDOR/BOLA, privilege escalation, tenant leakage |
|
Student-project example |
A student logs in |
The student sees only their own result |
Authentication and authorization are separate security functions. The OWASP Top 10:2025 ranks Broken Access Control at A01 and Authentication Failures at A07, reinforcing why a valid login cannot replace resource-level permission checks.
How Both Layers Work Together
Suppose a student requests:
GET /api/attendance/482
The application should not trust the record ID merely because the request contains a valid session or JWT. It must validate the identity and tenant, load the record safely, determine ownership or assignment, identify the requested action and check whether the operation is allowed in the record’s current state.
This is why hiding an “Admin” button is not authorization. A user can bypass the interface and call an endpoint directly. The backend remains the policy-enforcement boundary.
Four Authorization Levels Students Should Design
1. Function-Level Authorization
Function-level checks decide whether a user may call a feature or endpoint. For example, only an administrator should access POST /api/users or DELETE /api/courses/:id.
2. Object-Level Authorization
Object-level checks decide whether the user may access a specific record. Changing /students/101 to /students/102 must not expose another student’s data.
The OWASP API Security Top 10 calls this Broken Object Level Authorization. It is closely related to insecure direct object reference, or IDOR. OWASP recommends an object-level permission check whenever an endpoint accesses a data source using a user-controlled identifier.
3. Property-Level Authorization
A user may be allowed to view a record but not every field. A student might view a profile while fields such as disciplinary notes, internal remarks or password hashes remain excluded.
4. Tenant-Level Authorization
In a multi-college, multi-company or multi-department application, every query must remain inside the authenticated user’s tenant. A valid user from College A must never access College B’s records, even when the object ID is known.
Choose the Right Authorization Model
|
Model |
Best use |
Example |
|
RBAC |
Clear, stable user roles |
Student, Faculty, HOD, Admin |
|
ABAC |
Decisions depend on attributes or context |
Faculty may edit marks only for assigned subjects before the deadline |
|
ReBAC |
Access depends on relationships |
Owner, supervisor, team member, collaborator |
|
ACL |
Permissions differ for individual resources |
A shared file lists users who can read or edit it |
RBAC is usually the best starting point for a final-year project, but role checks alone are rarely enough. Combine RBAC with ownership, tenant, assignment and record-status rules.
Build an Access-Control Matrix Before Coding
A matrix converts role descriptions into testable requirements.
|
Resource or action |
Student |
Faculty |
HOD |
Admin |
|
View own attendance |
Allow |
Assigned classes |
Department |
All |
|
Update attendance |
Deny |
Assigned classes |
Department override |
All |
|
View marks |
Own only |
Assigned subjects |
Department |
All |
|
Approve final marks |
Deny |
Deny |
Allow |
Allow |
|
Manage user accounts |
Deny |
Deny |
Deny |
Allow |
Use deny as the default. Every allowed cell should become a backend policy plus positive and negative tests. The matrix also strengthens the requirements, design, testing and viva sections.
Step-by-Step Implementation Guide
Step 1: Inventory Subjects, Resources and Actions
List every human or service identity, protected resource and operation. Use precise verbs such as read, create, update, approve, export, assign, refund and delete.
Step 2: Select the Authentication Architecture
Use server-side sessions for a conventional server-rendered application unless separate API clients require tokens.
For detailed guidance on sessions, JWT, OAuth, MFA and passkeys, read FileMakr’s authentication methods for web applications.
Step 3: Centralize Identity Verification
Create authentication middleware that validates the session or token and attaches a trusted user object to the request. Controllers should not repeatedly decode unverified client data.
Step 4: Centralize Policy Decisions
Avoid scattered conditions such as if (role === "admin") across controllers. Use a policy function or service that receives the subject, action, resource and context.
function can(user, action, record) {
if (record.tenantId !== user.tenantId) return false;
if (user.role === "admin") return true;
if (action === "read" && user.role === "student") {
return record.studentId === user.id;
}
if (action === "update" && user.role === "faculty") {
return record.facultyId === user.id &&
record.status === "draft";
}
return false;
}
async function authorizeAttendance(req, res, next) {
if (!req.user) {
return res
.status(401)
.json({ message: "Authentication required" });
}
const record = await Attendance.findById(req.params.id);
if (!record) {
return res
.status(404)
.json({ message: "Record not found" });
}
const action = req.method === "GET" ? "read" : "update";
if (!can(req.user, action, record)) {
return res
.status(403)
.json({ message: "Access denied" });
}
req.attendance = record;
next();
}
This example checks tenant isolation, role, ownership or assignment, action and record state. Production code also needs validation, safe error handling, logging and security review.
Step 5: Apply Policies at the Correct Boundary
Run authorization before returning data or changing state. Filter database queries by tenant and ownership wherever practical instead of loading an unrestricted record and relying only on a later check.
Step 6: Handle Permission Changes and JWT Staleness
A self-contained JWT may contain an old role until it expires. Use short-lived access tokens, server-side permission checks, token revocation or a user/session version that changes when roles are updated.
Document the chosen consistency model rather than claiming permissions disappear instantly when they do not.
Step 7: Log and Test Denials
Record authentication events, role changes, sensitive actions and denied access without logging passwords or complete tokens. Repeated denials can reveal misuse, broken interface flows or attacks.
Authorization Test Matrix
|
Test |
Expected result |
|
Student requests their own attendance record |
200 |
|
Student changes the ID to another student’s record |
403 or privacy-preserving 404 |
|
Faculty updates an assigned class in an editable state |
200 |
|
Faculty calls an admin-only endpoint |
403 |
|
Request has no valid session or token |
401 |
|
User from another tenant requests a known record ID |
403 or 404 |
|
Disabled user reuses an old session |
Rejected |
|
User with a revoked role uses an old JWT |
Rejected through revocation/version check, or after the documented short expiry |
|
Hidden frontend control is called directly through Postman |
Rejected |
Happy-path testing proves authorized users can work; negative testing proves unauthorized users are blocked.
Common Authorization Failures
The most damaging mistakes are predictable:
- checking roles only in JavaScript;
- trusting an object ID supplied by the client;
- granting broad access to every authenticated user;
- forgetting tenant filters in database queries;
- exposing restricted fields in API responses;
- duplicating inconsistent policy logic across controllers;
- storing long-lived permissions in tokens without a revocation plan;
- returning data before the authorization decision;
- testing allowed actions but not denied actions.
Use 401 Unauthorized when valid authentication is missing and 403 Forbidden when the identity is known but lacks permission. Some applications return 404 Not Found for inaccessible objects to reduce record enumeration.
Advanced Design Insight: Separate Enforcement from Decisions
A maintainable architecture separates:
- Policy Enforcement Point: middleware, route guard, API gateway or service that intercepts the request;
- Policy Decision Point: the component that evaluates whether access is allowed;
- Policy Information: roles, ownership, tenant, resource state, assignment, time or risk context.
This separation makes policies reusable, testable and easier to explain. It also supports migration from RBAC to attribute- or relationship-based rules.
Frequently Asked Questions
Is authentication the same as authorization?
No. Authentication verifies identity. Authorization decides which resources and actions that identity may access.
Which comes first?
Authentication normally comes first for protected user operations. Public resources may be available to anonymous users through an authorization policy that does not require login.
Is JWT authentication or authorization?
JWT is a token format. It can carry identity and permission claims, but security depends on how the token is issued, validated, stored, expired, refreshed and revoked.
Is OAuth an authentication protocol?
OAuth 2.0 is primarily an authorization framework for delegated access. OpenID Connect adds an identity layer commonly used for authentication. Current OAuth security practice is documented in RFC 9700.
Is RBAC enough for a student project?
RBAC is a strong starting point. Add ownership, tenant, assignment and status checks whenever users with the same role should not access the same records.
What is IDOR or BOLA?
It is an object-level authorization failure in which changing or guessing a record identifier provides access to an object the user should not control.
Should authorization run on every API request?
Yes, for every protected operation. A valid session proves identity, not permission for every object or action.
What should students include in the project report?
Include the role-permission matrix, authentication sequence, policy architecture, protected routes, database relationships, threat analysis, authorization test matrix, screenshots of denied requests and expected-versus-actual results.
Conclusion
Authentication and authorization form one security pipeline but solve different problems. Authentication establishes a trusted identity. Authorization continuously limits that identity according to role, ownership, tenant, action, relationship and context.
For most final-year projects, use secure authentication, centralized middleware, RBAC plus object-level rules, deny-by-default policies, tenant-aware queries, audit logs and negative tests. Start with the access-control matrix before writing routes; it improves the application, documentation, testing evidence and viva defence.
Students building the API layer can continue with FileMakr’s guide to building a secure REST API for a student project. You can also explore final-year project ideas or relevant project source code when planning a complete implementation.
